SCRUM BOOT CAMP THE BOOK

https://gyazo.com/8664ba8549b54ae977fb6e02d64d0595

著者

出版

全体的に「そうだね」となる部分がおおいので引用などは少なめ。

基礎編 スクラムってなに？

アジャイル開発とは？で「作っているもの自体や計画を調整する」という文章がありよかった。計画も調整していくんや。

重要なもの、リスクの高いものほど先に作り、そうでないものは後回しにすることで成果を最大化していきます。

身近なところもで、つい「できるところから」やってしまいがちなんだけど、リスクがあるもの、不確実性の高いものからとりくまなきゃいけないんだよな。

5つのイベント、3つのロール、3つの作成物

スクラムで定められているのはこれだけだよ

実践編 どうやればうまくいくの？

このような意見を遠慮せずに言えるコツは、プロダクトオーナーの役割である「プロダクトの価値を最大化すること」、すなわち「ユーザーにどうしたら素早く高い価値を届けられるか」を常に意識し続けることです。

なるべく詳細にすることで見積りが確実になると思うかもしれないが、それはあくまでも詳細に推測しているだけなんだ。

見積りはどこまでいっても見積りでしかないんだよな。

リリースのための作業って特別扱いなの？

最初はリリーススプリントをリリースの前にいれて、そこでリリースに必要な作業をするといい。リリース可能なインクリメントを作り続けるのが一番よいけど、そこまでできるチームかどうか、メンバーや経験をみて決めよう。

もしスクラムを始めたばかりなら、まずはタイムボックスを守ることからはじめてみよう。　

なるほど。まずは時間を守ってみて、そこから課題をあげてみるのはよさそう。デイリースクラムが盛り上がりすぎる、みたいなのはこういうので見つかる典型例っぽい。時間を守るという部分がチームで合意できていないと、ふりかえりなどでも課題として出しにくいし、なあなあになりがち。

ロールで担当する部分を分けているので、どこに問題があるかわかるんだな。

この視点はなかったので勉強になった。

まずは、みんなの見えるところにそれらを張り出そう。そして、スクラムマスターはそれを率先して解決していくんだ。

スクラムチームはゴールに向かえるように絶えず工夫をしよう。そのためには、スクラムチームが今より上手く仕事をすすめるか、何かを調整するしかない。けれど、どちらもゴールにすぐに大きく近づくことはできないんだ。

よい言葉。

できないことを断わるのも責任を持つことなんだ。

はい……

リリースに必要な作業 = リリースを満たす基準 - 完成の定義

リリーススプリントがあるのを言い訳にして、必要なことを後回しにしてはいけない。それは、わかっているリスクを放置しているだけなんだ。

「リリース前にやろう」と先延ばしするとロクなことがないですよね。よい言葉だった。